|
||||||
|
Written By:
川俣 晶 |
||||||
|
りすと亭の開発は昨日で一段落としたかったのですが。 結局、今日もコードを書くことになりました。 今日の主な作業は、過去ログ再作成の機能の全面的な叩き直しです。 メッセージ数が膨大な(10万以上)リスト板の過去ログ再作成を行うと、Webブラウザがタイムアウトしてしまい、そのあとも処理が進みますが、エラーがあっても原因が全く分かりません。また、何時間も処理に要すると途中でメールが飛んできたり、いろいろなトラブル要因があります。 そういう事情を考えると、そもそもWebブラウザ経由で処理を実行するという方法そのものが問題だと言えます。そして、再作成中も様々な機能が止まっていないことも問題と言えます。 というわけで、Webブラウザからは処理をリクエストする処理だけを行い、実際の処理はバックグラウンドで行うという方針に転換しました。 その際、システム全体をメンテナンスモードに入れ、様々なサービスを処理しないようにしました。メールの受信を行わない、簡易httpd機能も503 Service Unavailableを返して処理しない、APIもLTServiceUnavailableExceptionを返して処理しない、という仕様に転換しました。エラーがあった場合は、イベントログに記録、またはサーバ管理者宛メールを送ります。 その際、問題になるのは、リスト板単位での再作成処理です。この方法は、りすと亭システムを、1つのポート単位でロックすることになります。しかし、1つのリスト板の再作成処理で全体をロックするのは不適切です。そこで考えました。そもそも、どうしてリスト板単位での再作成処理が必要であったのか。 本来、再作成処理は以下のような用途で使うものです。 1) ファイル破損を修復 2) ディスク節約のため古いメッセージを削除したあとの整合性の確保 3) 古いバージョンからバージョンアップしたあとの整合性の確保 このうち2)はリスト板管理者が扱う処理で、他の2つはサーバ管理者が扱う処理と言えます。しかし、りすと亭は既に、ディスク容量を拡大するための古いメッセージを削除する機能をリスト板管理者向けに提供しています。つまり、2)の機能は古いバージョンで必要だったかも知れませんが、今は必要ありません。そのような理由から、リスト板管理者向けの過去メッセージ再作成は取り除きました。 というわけで、Beta-030のリリースです。 これで全て丸く収まってくれると嬉しいところですね。 |
